<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Eclipse 3.0 adapter issues</title>
  <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body text="#000000" bgcolor="#FFFFFF">
 
<h1>Eclipse 3.0 adapter issues</h1>
<font size="-1">Last modified: February 16, 2004</font> 
<p>
This document outlines proposed changes in the 3.0 timeframe to the 
<tt>IAdapterManager</tt> infrastructure.  Related bug reports contain
much of the rationale and discussion:
</p>
<ul>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=32498">bug 32498 - Support to contribute adapter factory via XML</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=32436">bug 32436 - Using adapters to filter UI selections without loading plugins</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=30577">bug 30577 - Actions should check for IAdaptable#getAdapter(IJavaElement.class)</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36968">bug 36968 - [Plan Item] Improve action contributions</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37937">bug 37937 - [plan item] Support Java references outside Java code</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li>
<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29809">bug 29809 - Rename/Delete Action hooks [refactoring]</a></li>
</ul>
<h3>Current limitations</h3>
<ul>
<li>Nothing is known about an adapter factory until the plugin that provides the
adapter is loaded. This makes it difficult to calculate if an action contribution
or refactoring participant may potentially be applicable for a given selection until
it is executed.</li>
<li>The current API only supports returning a single adapter for a given adaptable
type.  For example, only one factory is allowed to adapt IFile to IPropertySource. 
In some contexts, it is appropriate to obtain all possible adapters on a type. Several
plug-ins may want to supply an IPropertySource or an IActionFilter for IFile.
</li>
</ul>
<h3>Proposed solution</h3>
<p>
Add the following three new methods to IAdapterManager:<br>
<pre>
public boolean hasAdapter(Object adaptable, String adapterTypeName);
public Object getAdapter(Object adaptable, String adapterTypeName);
public Object[] getAdapters(Object adaptable, String adapterTypeName);
</pre>
</p>
<p>
<tt>getAdapter</tt> returns the first non-null adapter found as it does today (transitive 
search of superclasses and then super-interfaces).  <tt>getAdapters</tt> returns all adapters 
for all superclasses and interfaces of the supplied object.  Only factories belonging 
to loaded plug-ins will be consulted by the <tt>getAdapter*</tt> methods.  <tt>hasAdapter</tt> consults 
both loaded and unloaded factories.
</p>
<p>
A new "adapters" extension in the runtime plug-in will specify the name of the factory 
class, removing the need for plug-ins to explicitly register their adapters on startup 
(they would be lazily registered on the first lookup on that factory after the plug-in is loaded):
<pre>
&lt;extension point=&quot;org.eclipse.core.runtime.adapters&quot;&gt;
   &lt;factory 
	class=&quot;org.eclipse.jdt.internal.ui.JavaElementAdapterFactory&quot; 
	adaptableType=&quot;org.eclipse.jdt.core.IJavaElement&quot;&gt;
      &lt;adapter class=&quot;org.eclipse.core.resources.IFile&quot;&gt;
      &lt;adapter class=&quot;org.eclipse.ui.views.IPropertySource&quot;&gt;
      &lt;adapter class=&quot;org.eclipse.ui.model.IWorkbenchAdapter&quot;&gt;
      ...
   &lt;/factory&gt;
&lt;/extension&gt;
</pre>
</p>
<p>
This extension point specifies a factory that adapts IJavaElement to IFile, IPropertySource, etc. 
Of course, for backwards compatibility we will continue to support adapters 
registered manually that do no have associated markup.
</p>







</body>
</html>